1. Field of the Invention
This invention relates to a computer system and method for displaying text having consistent look and feel upon the display of a server that interfaces with a client via the X window protocol. The text is rendered upon the display using a distributed network of computers, in order to assure the appearance and behavior of the graphical user interface is consistent across multiple diverse computers within the network.
2. Description of the Related Art
The continuing proliferation of faster and more powerful computers has been accompanied by an increase in the use of graphical user interfaces. A graphical user interface (or, GUI) offers many advantages over traditional text-based interfaces. A graphical interface may allow multiple application programs to present output simultaneously, each in a distinct window. Thus, it is not necessary to halt one application in order to interact with another. Instead of entering text-based commands and parameters, the user selects icons with a pointing device, such as a mouse. This is faster, easier and less error prone than making these selections using the keyboard. A GUI can convey a great deal of information to the user in a very accessible format. To a large extent, GUIs have displaced text-based interfaces.
It is possible to efficiently allocate computing and display resources among multiple networked computers through the use of a remote graphical user interface. With a remote GUI, an application may execute on one computer, while the user interface appears on another, possibly physically remote from the first. For example, a remote GUI may be used to allow multiple users sitting at remote terminals to access a central mainframe computer. In this scenario, the users share the computing resources of the mainframe, which simultaneously executes each user's application. A user interface at each terminal receives input from the respective user, and displays output from his application. Implementing a remote GUI raises look and feel issues, since the central computer is able to exchange data with each remote terminal, but has no direct control over how the data is rendered by its user interface. As used herein, the “look and feel” of a GUI refers to such things as the appearance, color and behavior of Buttons, TextFields, Listboxes, menus, etc. and their mouse, keyboard handling and behavior. To further complicate matters, the remote terminals may be of diverse types, with different graphics capabilities. This makes it difficult to properly create the graphical display in the central computer by anticipating the display characteristics of the remote terminal. A more feasible approach is to forward data generated by the application running in the central computer to the terminal in a platform independent format and allow the terminal to create the display.
The X Window System (or simply “X”) was introduced in the early 1980's as a cross-platform, client/server system for managing a windowed graphical user interface in a distributed network. X is frequently employed to provide windowing services in networked computers running the Unix operating system, or various other Unix-family operating systems, such as AIX, OS/390 or Linux. For example, an application running in a remote computer can request a graphics display device (i.e., another computer, or a “dumb” terminal) to create a screen graph depicting data generated by the application. The X protocol specifies a device independent format for the exchange of graphic images between (possibly, very different) computers over a network, based on an asynchronous network standard for communication between the two computers. According to this standard, the remote computer making the request has a certain amount of control over the display operation—it can specify general characteristics of the display, such as the relative position and orientation of the objects in the display. However, it relies on the remote display device to perform the low level functions required to actually produce the image.
To create a common windowing system, by which graphic images may be exchanged between different computers, the X protocol specifies both a device dependent and a device independent layer. A device independent description of an image may be sent from computer A to computer B, even if the machines have very different architectures. Upon receiving the device independent image description, the X software running on computer B translates it into a device dependent description, corresponding to the particular hardware configuration on that computer, thus allowing the image to be displayed.
When referring to networked computers, it is common to categorize an individual computer as a “client” or a “server.” This nomenclature is based on the information exchanged or services performed between two or more computers. For example, several computers in an office may be connected over a network to a central computer that manages a printer. Use of the printer is shared among the networked computers, who obtain access to it by sending requests to the central computer. In this scenario, the central computer operates as a print server, since it supplies a service (namely, printing) to the various clients with print jobs. Similarly, an application server may execute a prescribed program when requested by a client. For example, a supercomputer may function as an application server by running a finite element simulation on data supplied by a personal computer acting as its client.
It is customary for an application server to be a larger, more powerful computer than its clients, since it often has to serve several client requests at the same time. Notably, X reverses this paradigm. In the X Window model, the server is the system providing graphic display services to the system running the application. Thus, in the example above, the supercomputer would be considered an X client if, after completing its calculations, it called upon the graphics resources of a smaller computer to display the results. In a typical scenario, a user seated at an X server computer runs an application on a remote X client computer. X is an event driven interface—requests are made from the client to the server, and events propagate from the server to the client. When the user employs the mouse, keyboard, or a drawing pad to interact with the X client, the client decides how to respond to the input (for example, redraw a window, open a menu, and so forth). The X client then sends a request to the X server, asking for the appropriate action to take place. In response, the X server interacts with the system's graphics adapter, whereby the appropriate output is displayed on the user's screen, and relays this event back to the X client. Note that the X server does not initiate actions itself; it only performs actions that are requested by the X client.
Strictly speaking, the terms X client and X server may denote software programs fulfilling the functions described above, as opposed to the computers associated with these functions. For this reason, it is possible for an X client and an X server to reside on the same machine. In general, however, the client and server programs are on separate machines, connected by a network. Throughout the remainder of this application, it will be assumed that this is the case. Also, the terms X client and X server will be used within the context of this application to denote the client and server programs, respectively, rather than the computer platform on which they reside.
An issue that arises regarding the use of a remote GUI is that of look and feel consistency. Unlike most other windowing systems, such as Windows and Macintosh, X itself provides no inherent look and feel. Instead, each application provides its own look and feel. However, once a graphic image is received from the X client, the exact manner in which it is displayed depends entirely on the X server. For example, if the image contains text, the appearance of the text may vary according to which fonts are available in the X server, or the particular text drawing routine it uses. Thus, the GUI associated with an application may present a substantially different (and sometimes unsatisfactory) look and feel, depending on the X server being used to display it.
In the evolution of modern programming languages, the object-oriented paradigm has arisen to enable faster development of complex software programs. It encourages the use of consistent interfaces between program modules, and is conducive to the creation of reusable code. These features are highly advantageous in the development of large, intricate software programs, requiring the coordinated effort of several programmers. A departure from traditional programming languages, the object-oriented paradigm is based on objects, rather than procedures. Object-oriented programming (OOP) takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. The fundamental entities in an OOP language are classes created by the programmer, which possess properties appropriate for their intended purpose. Once a class has been defined, one or more objects can be created as instances of the class. Individual objects possess all the attributes of the class they represent. For example, a program for a graphical user interface might contain objects such as windows, menus, buttons, etc. having properties such as color, size, location on screen, etc. In addition to their properties, objects also have methods. Methods are actions supported by the object, by means of which they interact with other objects or respond to external events. In most OOP languages, it is possible to define new classes as extensions, or subclasses, of previously defined classes. In such cases, the child class inherits the properties and methods of the parent class, in addition to further methods and properties introduced by the programmer in the child definition. For example, a “jet” class can be defined as a child of an existing “airplane” class, with added properties, such as “turbine velocity.” Once the subclass exists, the programmer is free to create new objects with jet-like properties.
Java is a modern OOP language, designed with an emphasis on portability. As used herein, the term “platform” refers to a specific combination of hardware and operating system. More specifically, a platform consists of an operating system, the computer system's coordinating program, which in turn is built on the instruction set for a processor or microprocessor, the hardware that performs logic operations and manages data movement in the computer. A software program is said to be “portable” across various platforms if the program can run without modification on any of those platforms. This “write once—run anywhere” principle is the underlying philosophy behind programming languages such as Java. Java was introduced by Sun Microsystems in 1995 for use in the distributed environment of the Internet. It is an object-oriented programming language that can be used to create complete applications either for execution on a single computer, or to be distributed among servers and clients in a network.
The portability of Java depends on the presence of a Java virtual machine (JVM) in the target computer (i.e., the computer on which the Java application is to execute). A JVM “translates” the generic Java code into instructions specific to the target machine (i.e., “native” code) at runtime. Therefore, the same Java program can run without modification on any computer for which a JVM exists.
Among the uses for Java is GUI development, where the portability of Java code is highly advantageous. As used herein, the “look and feel” of a GUI refers to such things as the appearance, color and behavior of Buttons, Listboxes, and other graphical controls used to interact with the program. Often, a software program is intended to run on various machines, or under various operating systems, while maintaining a consistent look and feel. If the GUI is written in Java, a great deal of the code can be common across platforms, since Java is portable. This shortens development time, since the developer only has to write one version of the GUI code to be ported to all of the desired target machines or operating systems. It also improves maintainability of the code. When bug fixes or feature upgrades are necessary, they are confined to one version of the code, rather than several machine/system-specific versions.
Unfortunately, the portability of Java does not guarantee a completely consistent look and feel for Java applications in distributed computing environment, such as a Unix computer network employing the X Window system. According to the remote GUI concept of X, the application and its graphical interface may reside on two entirely different machines. Traditionally, Java applications create their user interface using a software interface known as the abstract windowing toolkit (AWT). The AWT is a type of application program interface (API) providing windowing support for Java applications. An API is an interface used by applications to access operating system services. By making calls to the API, an application program can invoke the resources of the operating system, for example, to write to the computer screen or detect the position of the mouse cursor. In Unix systems, where the GUI is separated from the application, the AWT relies on Motif. Motif contains a library of routines that make the creation of user interfaces in an X environment fairly easy and straightforward. The Motif libraries handle most of the low-level event handling tasks common to any GUI system. The AWT, which is part of Java, utilizes the features of Motif on Unix (just as it uses Win32 APIs on Windows), to provide GUI frames and controls (such as push buttons, menus, listboxes, entry fields, etc). Because the GUI is remote from the application, the user can be sitting at a display that is physically located in a different location from the computer that is running the Java application program. The application (X client) uses the network to communicate drawing commands to the remote display (X server), where the user is actually sitting. However, due to the platform-dependence of the AWT, different X servers may implement these drawing commands differently. As a result of these dissimilarities, the appearance of buttons, lists, checkboxes, etc. created by a Java-based GUI may vary when the GUI is displayed on different X servers.
Thus, in the case of a remote graphical interface such as that provided by X, the application has no direct control over specific characteristics of the GUI presentation—instead, this is a function of the hardware and software in the X server. This gives rise to a number of problems affecting the consistency of the GUI look and feel, and, in particular, the quality and performance of text generation.
Among these problems is the fact that Java applications cannot avail themselves of the high quality font rasterizer (T2K/Freetype) included in IBM's version of the Java JVM. A font is a complete character set of one point size and face—e.g., courier bold, 12 point. A font rasterizer transforms font codes (e.g., ASCII or Unicode) into glyphs. A glyph is the visual representation of a character within a given font, which may be displayed on the computer screen as text. For example, an italic ‘a’ and a roman ‘a’ are two dissimilar glyphs representing the same character. The italic ‘a’ and the roman ‘a’ have dissimilar pixel bitmaps, and therefore, dissimilar glyphs. For Java applications running on platforms with a local display, the T2K rasterizer in the JVM draws high-quality text to the screen. However, in remote displays the text rendering is delegated to the X server's rasterizer. Unfortunately, in some of the Unix family operating systems, such as AIX, the rasterizer does not provide clear or “crisp” text renderings. Furthermore, even if the quality of the text is acceptable, its glyph appearance may not be consistent when presented on different servers, due to variations in the Motif implementations installed on different platforms. Moreover, some X servers cache an entire set of glyphs for each font that's needed. In the case of Asian text, the number of glyphs can be quite large, which can degrade the servers performance.
TextArea and TextField in the Java legacy AWT serve as another example of the inconsistencies and limitations in the implementation of controls in the various Unix family platforms. On some platforms, TextArea and TextField controls are limited to only one encoding and one font at a time. An encoding is a mapping of binary numbers to the individual characters in a character set. For example, the traditional ASCII (American Standard for Information Interchange) encoding assigns an integer from 0 to 255 to each of the upper and lower case letters of the standard Phoenician alphabet, along with the numerals from 0 to 9 and various common typographical symbols. In a Unix system there are typically a variety of “localized” encodings, generally associated with foreign character sets. Being limited to one font at a time could present a problem, for example, when displaying a TextField with a string containing both Courier and Symbol fonts. Likewise, text containing mixed language characters would confound a system restricted to one encoding at a time. Furthermore, many operating systems do not support the use of Unicode encodings. Unicode is a new standard for associating binary codes with text or script characters. Officially called the Unicode Worldwide Character Standard, it is a system for the interchange, processing, and display of written text in all the major languages of the modern world. Currently, the Unicode standard contains 34,168 distinct coded characters derived from 24 supported language scripts, covering the principal written languages of the world. Unicode support is built into Java, and is important for a universal, platform-independent GUI. However, reliance on the diverse platform-specific AWT implementations presents an obstacle to the general use of Unicode.
Beyond these look and feel issues, maintenance and support of the numerous platform-specific versions of the AWT can be burdensome, and achieving uniform behavior among them practically impossible. In order to add a new feature to the GUI, for example, it is necessary to modify dissimilar code in the AWT for each supported platform. Moreover, it may be extremely difficult to obtain consistent behavior from the added feature, because of code differences in the platform-specific AWTs. Moreover, some of the sundry Motif implementations, on which the AWT depends, are not entirely stable, further complicating troubleshooting efforts. It is not possible to merge the diverse heavyweight AWT variants because, as noted earlier, they are highly hardware dependent. Consequently, there can be no universal AWT that is compatible with the disparate hardware configurations on each of the various platforms.
In view of these and other related difficulties, it would be desirable to have a single API for Java applications that would work with all supported Unix-family platforms in an X Window-based distributed network. The desired API should provide consistent, high-quality text drawing, along with support for multi-font strings and international character sets.